This invention relates to the installation of program modules from more than one available source. In particular, this invention relates to the installation of updated program modules from one or more updated sources instead of from an older, standard source.
Described herein this document are issues and techniques related to the Microsoft(copyright) Windows(copyright) operating systems (such as Windows(copyright) 95, Windows(copyright) 98, Windows NT(copyright), Windows(copyright) 2000, Windows(copyright) Me). However, those of ordinary skill in the art understand and appreciate that the issues and techniques described herein may be applicable to any operating system (OS) that support an expansive and updateable set of hardware devices. Examples of such operating systems include: OS/2(trademark), Linux, Unix(trademark), Mac OS(trademark), and BeOS(trademark).
In particular, the issues and techniques described herein are applicable to an OS that support plug-and-play (PnP) technology. PnP refers to the ability of a computer system (and its supporting OS) to automatically configure expansion boards and other hardware devices. With PnP, a user should be able to plug in a device and play with it, without worrying about setting DIP switches, jumpers, and other configuration elements.
Herein, an exemplary xe2x80x9cOSxe2x80x9d is discussedxe2x80x94this OS may be any OS having the issues discussed. The details of the implementation of a particular OS may differ from the exemplary OS described herein, but issues faced by such an implementation may be same or similar.
Initial Hardware-Specific Program Module Installation
FIG. 1 shows a typical personal computer 50. When first manufactured, a computer does not have an OS. Thus, the OS needs to be initially installed. In addition, the OS of existing computers are upgraded to a newer version of an OS.
Floppy disk(s) 62 and CD-ROM 64 represent potential OS installation source for computer 50. Also, server 30 represents a potential OS installation source for computer 50 over network 40.
Typically, an OS installation source (in a storage medium) contains a wide array of program modulesxe2x80x94many of which are only installed if there is a need to do so. Block 66 illustrates examples of some of the program modules that might be found on an OS installation source: setup program 66a core program modules 66b, and standard cabinets (xe2x80x9ccabsxe2x80x9d) 66c of hardware-specific program modules. Cabs are a series of linked compressed files in which hardware-specific program modules are stored. These hardware-specific modules are only necessary (and thus only need to be installed) when particular hardware is present in the computer.
This installation process is typically referred to as xe2x80x9csetup.xe2x80x9d The program that performs the installation is typically called the xe2x80x9csetup program.xe2x80x9d Program modules may be simply called xe2x80x9cfilesxe2x80x9d when referring to their status when stored on a storage medium.
During setup, program modules are unpacked and copied from the installation source onto the primary non-volatile storage system (such as a main hard drive 70 of FIG. 1) of the computer 50. This program-module duplication and organization has three major steps.
Core Files. First, the setup program copies the OS""s core program modules (i.e., files) from the source represented by subblock 66b to a storage location 70a of the hard drive 70 of the computer 50. These files are the same core files installed into every computer regardless of the exact hardware configuration. An example of such a core file is the kernel of the OS.
Enumeration and Detection. Second, the setup program examines the is hardware environment of the computer 50. It detects, enumerates, and identifies the hardware devices found during this step. It generates an enumerated list of program modules (such as a device drivers) that are associated the hardware devices found during this step. These program modules are located in the standard cabs 66c of the installation source 66.
Hardware-Specific Program Module Installation. Third, the setup program copies the program modules in the enumerated list. It copies them from the standard cabs 66c of the installation source 66 to a hardware-specific program module storage location 70b on the hard drive 70 of the computer 50.
Undating Installed Hardware-Specific Program Modules
Core and hardware-specific program modules are updated periodically to enhance features and functions and to fix known bugs and problems. Occasionally, a collection of such updated program modules are released in a package called a xe2x80x9cservice packxe2x80x9d (SP).
Typically, the service pack installation is very similar to the initial OS installation except only those program modules that need updating are replaced by updated modules in the SP. Because hardware-specific modules for other non-installed devices do not exist on the computer 50, only the hardware-specific modules of installed hardware devices are updated by the SP. After the SP installation, the computer 50 has the latest core and hardware-specific program modules for its current hardware configuration.
Some hardware-specific program modules are utilized by multiple hardware devices. Therefore, updating one of those modules improves, corrects, and/or enables the performance multiple devices.
SP may be delivered to the computer 50 in the same manner as the initial installation. For example, it may be a CD-ROM 64, floppy disk 62, or over a network 40 (from server 30).
Later Hardware-Specific Program Module Installation
Often hardware is added to computer 50 after the initial installation. These hardware devices need program modules (such as device drivers) for the computer and the OS to support them. Many of these hardware devices are Plug-and-Play (PnP) and are automatically recognized and identified by the computer and its OS. Each hardware device is associated with a hardware-specific program module (such as device driver). Therefore, a PNP-capable computer and its OS attempt to automatically install the hardware-specific program module associated with the newly installed and PnP-recognized device.
Conventionally, the exemplary OS assumes that the original installation source is the location from which to install the hardware-specific program modules for the PnP-recognized device. Therefore, the hardware-specific modules are drawn from the standard cabs 66c of the original source 66.
The new device installation process pulls the associated program modules from the standard cabs 66c regardless of whether such modules are the most current in light of the SP. The device installation does not provide an automatic mechanism to check for the latest incarnation of a device""s associated program module. Although it may provide a user a manual choice for a source location, this option is of little value unless the user knows from where to derive the latest file.
Assuming that its associated modules are obtained from the original source, a newly installed device on the computer 50 potentially has an old and possibly functionally out-of-date program module. Furthermore, if this is a common program module used by multiple devices, then the function and operation of other devices may fail or may result in incompatibilities.
Conventional Approach
Installation of an old hardware-specific program module when installing (or reinstalling) a just-detected hardware device may result in a problem. The old module has a potential to cause function failures, feature limitations, and/or incompatibilities.
The conventional approach to solving this problem is to educate the user to take additional steps after the just-installed device is installed. These additional steps involve manually installing an updated version (perhaps from a service pack) of the associated hardware-specific program module. This is a difficult approach because users expect the computer to automatically install the correct associated module because the installation is billed as plug-and-play (PnP).
Described herein is a technology for automatically updating the most current program modules associated with a just-detected hardware device. In one described implementation, a program-module updater generates a list of to-be-copied program modules. Typically, these modules are associated with just-detected hardware devices. This implementation of the updater stores a data structure for each module in such list. Each data structure includes an entry that indicates the source location of the associated module. For example and typically, the source location is the original source location for the installation of the operating system.
The updater implementation examines the list to identify any of the listed modules have been updated and it modifies the associated data structure of each updated module so that a source entry in each data structure indicates the updated source for the updated module. The updater copies all modules in the list to a hardware-specific program module storage location of a computer. The source of each module is indicated by its associated data structure.